home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
- Network Working Group Gregory M. Vaudreuil
- Internet Draft Tigon Corporation
- Expires 4/18/94 October 18th, 1993
-
-
-
- Application/Signature
- <draft-vaudreuil-mime-sig-00.txt>
-
-
- 1.Status of this Memo
-
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas,
- and its Working Groups. Note that other groups may also distribute
- working documents as Internet Drafts.
-
- Internet Drafts are valid for a maximum of six months and may be
- updated, replaced, or obsoleted by other documents at any time. It is
- inappropriate to use Internet Drafts as reference material or to cite
- them other than as a "work in progress".
-
-
- 2.Abstract
-
- The memo defines a MIME content type for the exchange of sender
- contact information and user agent capability information beyond what
- is feasable in the RFC822 header. This exchange is generally
- accomplished by use of a signature trailer appended to the message.
- These signatures commonly contain address, phone, and email
- addressing. This document outlines a formalization and extension of
- the signature concept to provide a machine readable, internationally
- friendly form to exchange this information.
-
- 3.Introduction
-
- Mechanisms for the exchange of contact information are lacking in the
- general internet. Directory services are not ubiquitous and it is not
- clear how to search for a given person even when they are available.
- The exchange of business cards provides a mechanism for identifying a
- specific person when you meet them. The application/signature body
- part provides a similar mechanism, to deliver contact information to a
- person you "meet" over electronic mail.
-
- The information to be exchanged between people over electronic mail is
- also growing. As Privacy Enhanced Mail grows in popularity, accessory
- information such as public keys becomes more essential to exchange
- with those who you normally contact. As Internet mail becomes multi-
- media, the exchange of information, such as a small portrait or short
- audio greeting become as useful as the RFC822 text name for
- identifying the sender.
-
- As the number of content-types, languages, and character sets
- increase, it becomes more essential to identify the capabilities of
- the destination mail agents without having to wait for error reports
- and letters of complaint. The Application/Signature body part
-
-
- Internet Draft Application/Signature Expires 4/10/93
-
-
- provides a mechanism for sending a list of MIME content-types, the
- character sets supported, and the languages spoken by the mailbox
- owner.
-
- By saving and caching the information provided in the
- application/signature body part, a database of destinations frequently
- contacted can be populated and updated. This database can be used for
- providing basic, local alias directory services and can be used by
- mailers to notify the sender before sending the message if it is
- supported by the receiver.
-
- Automated update of the database requires loosely standardized
- attribute/value pair definitions. These elements are based on the
- MIME content-type/sub-type registry. Each attribute registration
- includes all information needed to unambiguously identify the content-
- type, parameters such as character set, and transport encoding.
-
- This specification does not explicitly include a universal database
- key value. X.500 distinguished names and email addresses may provide
- a suitable mechanism for correlating updates and providing lookup
- functions.
-
- 4.Definition of the Application/Signature Body Part
-
-
- Mime type name: Application
- Mime Sub-Type name: Signature
- Required Parameters: None
- Optional Parameters: None
- Encoding Considerations: 7 bit is always sufficient.
-
- The application/signature body part should be included as the last
- body part in a top-level Multipart/Mixed construct.
-
- The Application/Signature body part is a sequence of attribute/value
- pairs formatted according to the rules of RFC 822 header lines. As in
- RFC822 headers, lines may be wrapped and continued on subsequent lines
- by indenting with linear white space. Comments are optional and are
- not considered part of the value if included.
-
- All lines must be in 7bit US ASCII format. Non US ASCII textual data
- can be represented using the RFC 1522 encoded word. Non-text data
- must be encoded using base-64 or quoted printable, with the specific
- encoding specified in the attribute definition.
-
- The list of allowable attributes is maintained by the IANA. Except
- for Text/Plain, registered values must correspond to exactly one
- previously registered MIME content-subtype and must include constant
- values for all necessary parameters and specify the transport encoding
- if needed. Use of X- for experimental and bi-laterally defined
- (Private) values is permitted.
-
- The attribute "Capabilities" is provided to identify the MIME content-
- types supported by the destination. The list of attributes should
-
-
- Vaudreuil [Page 2]
-
-
- Internet Draft Application/Signature Expires 4/10/93
-
-
- include any IANA registered content-type. To reduce the amount of
- data transferred, the list of capabilities should not include the
- basic MIME constructor types. These types are Message/RFC822,
- Message/Partial, Multipart/Mixed, Multipart/Parallel,
- Multipart/Alternative, and Application/Octet-Stream. Text/Plain if
- supported should be explicitly identified as some mixed media agents
- may not support text output.
-
- The attribute "Charsets" is provided to identify the character sets
- accepted for use in Text/* bodyparts. The list of character sets can
- include any IANA registered character set. US-ASCII does not need to
- be identified as it the default character set. The character sets
- should be listed in the order of preference.
-
- The attribute "Languages" is provided to communicate the languages
- understood by the mailbox owner. As communication becomes increasing
- global, a list of languages will allow the sender to choose an
- appropriate language without guessing. The set of language identifier
- can include any registered in XXXXX(need reference). The languages
- should be listed in the order of preference.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Vaudreuil [Page 3]
-
-
- Internet Draft Application/Signature Expires 4/10/93
-
-
- Initially Defined Application/Signature Values . 5
-
-
-
- Attribute Content Type Description
- Encoding
-
-
- Email Text/Plain A fully qualified domain name style
- 7bit address.
-
-
- Name Text/Plain The name of the mailbox owner. Latin
- 7bit derived names must be in the Last, First,
- Middle initial format for ease of parsing.
-
-
- Telephone Text/Plain The international version of the telephone
- 7bit number. Multiple telephone numbers can be
- differentiated by use of an RFC 822
- comment.
-
-
- Fax Text/Plain The international verison of the
- 7bit fascimilie number.
-
-
- Address Text/Plain The postal address, each line separated
- 7bit with a slash "/".
-
-
- Portrait Image/Gif A small bitmap portrait. This may be used
- Base-64 for visual message waiting identification.
-
-
- SpokenName Audio/ADPCM A short phrase containing the name in the
- Base-64 voice of the mailbox owner.
-
-
- Capabilities Text/Plain A coma separated list of the MIME content-
- 7bit types the mailbox owner is willing to
- accept. Message/RFC822, Message/Partial,
- Multipart/Mixed, Multipart/Parallel, and
- Multipart/Alternative are required and
- need not be listed.
-
-
-
- Text Text/Plain Free form text for comments, quotes, and
- 7bit ASCII art.
-
-
-
-
-
-
- Vaudreuil [Page 4]
-
-
- Internet Draft Application/Signature Expires 4/10/93
-
-
-
- Charsets Text/Plain A coma separated prioritized list of the
- MIME content-types supported by the user
- agent.
-
-
- Languages Text/Plain A coma separated prioritized list of the
- languages understood by the mailbox owner.
-
-
- PEM_Cert Text/Plain The PEM certificate of the mailbox owner
- 7bit as specified in RFC 1421.
-
-
- Distname Text/Plain The X.500 distinguished name of the
- 7bit mailbox owner.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Vaudreuil [Page ] 5
-
-
- Internet Draft Application/Signature Expires 4/10/93
-
-
- 6.Example Application/Signature Body Part
-
- Content-Type: Application/Signature
-
- Name: Gregory M. Vaudreuil
- Email: GVaudre@cnri.reston.va.us
- Telephone: +1 214 555 2121 (Work)
- Fax: +1 214 555 3232
- Address: 17080 Dallas Parkway/Suite 100/Dallas Texas, 75248
- Portrait: R0lGODdhEAAQAIAAAAAAAP///ywAAAAAEAAQAAACK4wNqceR7UCT8FB
- n2aUc47550nZ5iFZWVqpG2bS+WhbK3frYrYmwOaRYMAoAOw==
- Capabilities: Text/Plain, Image/GIF, Image/Postscript, Audio/Basic
- PEM-Cert:
- MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
- BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
- BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
- CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
- MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
- yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
- LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
- iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
- 5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
-
- 7.Security Consideration
-
- The information in the application/signature cannot be considered any
- more authoritative than the "from" line of the RFC 822 header.
- Authentication of the content is left to mechanisms specified in the
- Privacy Enhanced Mail extension to RFC 822.
-
-
- 8.Author's Address
-
- Gregory M. Vaudreuil
- The Tigon Corporation
- 17080 Dallas Parkway
- Dallas, TX 75248-1905
- 214-733-2722
- Gvaudre@cnri.reston.va.us
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Vaudreuil [Page 6]
-